home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d19
/
dorpch37.arc
/
SYSOP.DOC
< prev
Wrap
Text File
|
1991-01-01
|
12KB
|
257 lines
DOORPCH v3.7 DOOR Operational Information for SysOps
January 1, 1991
By
Raymond Clements
2204 Carriage Dr.
Owensboro, KY 42301-5823
(C) Copyright 1987-1991
All Rights Reserved
The Pegasus BBS
Node #1 - (502)684-9855
Node #2 - (502)684-9871 HST
RIME PCRelay routable ->PEGASUS
SysOp Operation
-----------------
Please include the following information with any DOOR you write
which uses DOORPCH v3.7. The SysOp will require the information.
Preface
---------
This is NOT meant to tell you how to setup DOORs on your BBS,
just how to setup DORPCH37 doors.
Support Shareware
-------------------
Thank you for obtaining this door program. Many hours of coding
have gone into its development. Like all shareware products,
you're encouraged to register this program if it meets your needs.
Supporting Shareware helps insure the future development of such
programs and will entitle you to support from their authors.
Environment Variables
-----------------------
Two environment variables must be set in your AUTOEXEC.BAT file:
SET LIB=<drive:><path to DORPCH37.EXE> Note: ONLY the PATH!
Example: SET LIB=C:\MYLIB
The DORPCH37.EXE run-time library must then be placed in this
directory. I'd suggest a separate directory as I do on my system.
SET DOORPCH=PCB This variable is required by prior versions
of DOORPCH, but not by DORPCH37.EXE.
For your convenience DOORPCH v3.7 also supports the following three
new variables:
%NODE% , %DRIVE% , and %DIRECTORY%
SET NODE=1 (ie. 1 , 2 , etc.)
SET DRIVE=C: (ie. C: , D: , etc.)
SET DIRECTORY=\BBS\ (ie. \PCB\ , \BBS\ , etc.)
These may be used to allow a single DOORNAME.CFG file for all nodes.
When using these variables please remember the combination of them
MUST form a valid DOS "drive:\path\" pointing to the location of the
BBS interface file.
DOOR Setup
------------
Make a batch file to run the DOOR as described in your BBS
documentation.
Example DOOR batch file:
--------------------------
CD\DOORS\4CARD
4CARD 4CARD.CFG <== Runs 4CARD.EXE passing
a parameter of 4CARD.CFG to it.
CD\BBS
BOARD
Example DOORNAME.CFG file:
----------------------------
It is highly recommended that none of the characters to the left
of the period in DOORNAME.CFG be changed. If you want to have
different DOORNAME.CFG files for each node then I would recommend
changing the characters to the right of the period instead.
(ie. 4CARD.CF1) You may also use the environmental variables to
only require one DOORNAME.CFG file for multiple nodes.
C:\BBS\DOOR.SYS <== The drive:\path\filename
of your BBS interface file
which is the same as
%DRIVE%%DIRECTORY%DOOR.SYS
using the above variables.
The Pegasus BBS <== The name of your BBS.
Raymond <== The SysOp's FIRST name.
Clements <== The SysOp's LAST name.
John Doe & Jane Doe <== The name(s) of the DOOR's sponsors,
if DOOR SECURITY SYSTEM is used.
Command-line parameters
-------------------------
This parameter may be used when starting a DOORPCH v3.7 DOOR.
/LOCAL <== Allows local usage of the DOOR as
the SysOp.
(ie. 4CARD 4CARD.CFG /LOCAL)
DoorPch v3.7 Utility: DP37Util
--------------------------------
These parameters may be used with DP37Util to setup and maintain
each DOOR's high score file and/or challenge ladder file.
/CREATE <== Creates the high score file and/or
the challenge ladder file.
(ie. DP37UTIL 4CARD.SCR /CREATE)
/PURGE:## <== Purge names from database if they
haven't used the DOOR in ## days.
(ie. DP37UTIL 4CARD.SCR /PURGE:21)
DOORNAME.SYS
--------------
If the DOOR uses DoorPch's internal DOOR SECURITY SYSTEM then
upon registering the DOOR you should receive a DOORNAME.SYS from
the author. (ie. 4CARD.SYS) This file should be put in the
DOOR's default directory.
Libraries
-----------
All DOORPCH v3.7 DOORs require the DORPCH37.EXE run-time library
and the Microsoft (R) QuickBASIC 3.0 run-time library, BRUN30.EXE,
be in your path. Your DOOR program may have come with these files
in the archive file. If they are not present, this DOOR program
WILL NOT RUN. You should contact the DOOR author if the files
are missing. You require one and only one version of these two
libraries for ALL DOORPCH v3.7 DOORware. The files are also
available in DORPCH37.ZIP available on most of the better Bulletin
Board Systems. If you wish a fully detailed explanation of how
DOORPCH operates with DOORS, then you may read the documentation
within the DORPCH37.ZIP file within which this documentation may
be found.
DOOR Operation
----------------
When this DOOR is in operation you have complete control over the
caller. This DOOR was written using DOORPCH v3.7. The logic is
safe and every precaution has been taken to insure this code works
flawlessly. If it doesn't, please let us know. Many
function/operational keys are at your disposal:
F1 - Displays the version of DOORPCH compiled and linked
into the DOOR.
F2 - Displays a caller's Alias if one is used via the DOOR.
F3 - Toggles Local Music ON/OFF.
F4 - Toggles the Bell ON/OFF.
Value is returned to BBS when DOOR completes.
F5 - DOS Shell. Allows the SysOp to exit to DOS from inside
a DOOR.
F6 - Toggles the Graphics mode of the caller ON/OFF.
Value is returned to BBS when DOOR completes.
F7 - Toggle the caller alarm ON/OFF.
Value is returned to BBS when DOOR completes.
F8 - Returns the caller involuntarily to the BBS.
F9 - Toggles the display ON/OFF.
Value is returned to BBS when DOOR completes. Some doors
may force the display ON, but the original OFF value will
be returned to the BBS if this occurs.
F10 - Activates SysOp/Caller CHAT mode within the DOOR.
ESC - Deactivates CHAT mode. DOOR is resumed.
ALT-H - HELP key for lines 24/25 capabilities.
UP - Allows the SysOp to add additional time for the caller.
Value is returned to BBS when DOOR completes.
DN - Allows the SysOp to subtract time from the caller.
Value is returned to BBS when DOOR completes.
ALT-N - Some BBSs use SysOp next on control/indicator.
Value is returned to BBS when DOOR completes.
ALT-X - Some BBSs will exit after current caller completes their
session. Value is returned to BBS when DOOR completes.
Example: DEVICE=ANSI.SYS
--------------------------
DOORPCH uses this device driver for displaying all colors and
screen positioning to the local console. Color Graphics will
always be sent to the local console if you are using a color
monitor. If a caller is in non-graphics mode you will still see
colors if you have a color monitor. The reverse is also true.
If the caller is in graphics mode and the local console is a mono
monitor then colors will NOT be displayed to the local console.
MUSIC
-------
This DOOR program may utilize ANSI music. If it does, and you
are running in a NETWORK, DOORPCH does not send ANSI music to the
local console unless you have it configured to. We have found that
under some Multi-Tasking operating systems such as DoubleDOS that
the "partition" locks up until the music completes. If you are on
a single node system (not in a network), then music will be played
to the local screen if the local screen is active (F9 ON) and you
have DOORPCH configured that way or local music is toggled on (F3 ON).
BELL
------
DOORPCH logic will not allow a BELL to be sent to the local
console when the local screen is inactive (F9 OFF) or the caller
alarm is toggled off (F7 OFF). This, of course, assumes the
DOOR author follows the DOORPCH rules.
ERRORS
--------
All errors should recover and cause the DOOR program to exit
gracefully and return to the main system. All errors are logged
in the "DOORPCH.ERR" file found in the "SET LIB=" directory. The
error number and line number are included with the date and time.
Errors will be either caused by the main module (the authors code,
contact him/her) or the DOORPCH sub (contact Raymond Clements).
It should NEVER cause the BBS to hang. If your BBS hangs, you are
requested to contact the appropriate party and report the error and
circumstances that caused it. Because we are using Microsoft's (c)
QuickBASIC 3.0 run-time routines, it is possible that BASIC will
detect a fatal error condition. As mentioned above, we have taken
every precaution, but simply cannot code for every error condition.
If the DOOR author follows all the rules, the DOOR should run without
error.